Siempre es satisfactorio compartir nuevas formas poderosas de resolver problemas, especialmente cuando la solución ha estado "a la vista de todos" durante un tiempo. Esta vez muestro cómo la combinación de ArcGIS Enterprise branch versioning y cloud native data sharing ofrece no solo acceso rápido a los datos, a personas sin acceso al portal, sino también la capacidad de pedir que los datos accedidos viajen en el tiempo hasta cuando eran más jóvenes. Como estos lotes, vea un lote previamente indiviso y ahora sus tres subdivisiones.<\/P>
Parcel subdivision<\/span><\/span>Parcel subdivision<\/SPAN><\/SPAN><\/SPAN><\/P>Imagine un conjunto de datos con millones de entidades y bajo mantenimiento diario intensivo, como branch versioning está diseñado para manejar, sus clientes pueden acceder a toda o cualquier parte de la versión predeterminada para cualquier momento en el tiempo. Para siempre. Sin carga adicional en su portal Enterprise.<\/P>Entonces, ¿cómo llegué aquí? Simplemente noté que el modelo de transacción solo inserción de branch versioning es adecuado para crear incrementalmente archivos GeoParquet en almacenamiento en la nube que preservan conjuntamente el estado de los datos a lo largo del tiempo y pueden ser consultados espacial y temporalmente para hacer datos locales bajo demanda para su área y tiempo de interés.<\/P>¡Sin embargo, es una consulta muy sofisticada! La buena noticia es que no tiene que descubrirla usted mismo, la descarga del blog incluye un notebook con ejemplos para mi tema de parcelas, solo inserte los suyos.<\/P>No tuve que inventar el enfoque de consulta, Esri publica materiales de taller sobre el tema. Por ejemplo, si va alrededor del minuto 18 en esta presentación, verá cómo se ve tal consulta.<\/P>Spoiler<\/a>agrega la clase archive al mapa están disponibles:<\/P>
Archive class added to the map<\/span><\/span>Archive class added to the map<\/SPAN><\/SPAN><\/SPAN><\/P>Un par de cosas a notar en el mapa de campos: ObjectID se degrada a un entero largo ordinario (los valores ya no son únicos) y se agregan varios campos llamados GDB_*. Estos permiten ver los datos en un momento dado, que es cómo funciona branch versioning - gana el estado más reciente para una entidad, que puede ser un estado eliminado, pero el historial de datos no se pierde (a menos que lo elimine), lo que hace posible el viaje en el tiempo.<\/P>La clase archive también es buena para descubrir qué momentos de edición hay en sus datos.<\/P>Con la clase archive proporcionando visibilidad a todos los campos, fue posible el flujo de trabajo de compartición y mantenimiento. Funciona así:<\/P>Crear un archivo parquet inicial con todas las filas de la clase archive donde GDB_BRANCH_ID = 0<\/LI>En cualquier horario que tenga sentido, crear archivos delta parquet para nuevos estados fila rama predeterminadosEstos tienen una GDB_FROM_DATE posterior al máximo en todos los archivos parquet existentes<\/LI>También tienen GDB_BRANCH_ID = 0<\/LI><\/UL><\/LI>Mantener todos los archivos parquet en su almacén favorito compatible con S3 en una ruta glob<\/LI>Dar a sus clientes de datos un notebook o herramienta script que puedan usar para extraer datosEl notebook suministrado requiere DuckDB versión 1.0.0 en el entorno Python<\/LI><\/UL><\/LI><\/UL>Ahora, estoy promocionando esto como distribución nativa en la nube, pero al escribir todavía estoy configurando mi cuenta AWS por lo que el notebook adjunto usa una ruta del sistema local, actualizaré eso cuando tenga una URL pública S3 disponible. Mientras tanto puede descargar datos de muestra para pruebas aquí, aquí, aquí y aquí. Son la copia inicial masiva versión y algunos archivos delta incrementales, con algunas ediciones diarias cada uno. Cambie la variable pqPath del notebook según su entorno hasta que tenga la ruta S3 disponible.<\/P>Spoiler<\/A>Los datos que estoy usando realmente no se mantienen en una geodatabase versionada por branch, hice datos de muestra, por favor vea permisos de datos en los detalles del ítem para los enlaces arriba.<\/DIV>
Los datos que estoy usando realmente no se mantienen en una geodatabase versionada por branch, hice datos de muestra, por favor vea permisos de datos en los detalles del ítem para los enlaces arriba.<\/DIV><\/DIV>
Verá en el notebook que proporciono una plantilla para consultas por extensión y viaje en el tiempo. Encuentro que puedo extraer las 2.7 millones de parcelas en mis datos en poco más de 3 minutos desde disco local. El acceso desde S3 esperaría sea un poco más lento, veremos cuando tenga eso configurado. Pruebe el notebook usted mismo.<\/P>
Podría tener algunas preguntas sobre el notebook, intentaré anticipar algunas:<\/P>
- Se usa DuckDB 1.0.0 ya que está en el canal Esri Conda y versiones posteriores manejan geometría diferente<\/LI>
- La columna bbox en los archivos parquet es tipo JSON pero consultada como varchar porque DuckDB parecía no reconocer los datos como JSON<\/LI>
- Intenté usar la pseudocolumna rowid incorporada en DuckDB pero obtuve errores, así que la sobrescribí<\/LI>
- Intenté escribir la clase entidad salida pasando por un dataframe habilitado espacialmente pero obtuve errores<\/LI>
- En la descarga del blog el proyecto atbx tiene una herramienta script que usé para encontrar anchos deseados para campos texto salida<\/LI><\/UL>
Ahora voy a ser un poco egoísta. Para hacer mis datos muestra y archivos parquet construí algunas herramientas ETL (Pro 3.4), las cuales podría haber scriptado. Estas herramientas no están en la descarga del blog. Si le interesan por favor envíeme un mensaje y puedo compartirlas. Ayudará al equipo aquí si sabemos cuántas personas están interesadas en este paradigma de compartición de datos, así que por favor ayúdenos a ayudarle.<\/P>
